This section covers the logic and data formats used in order to implement the functionality addressed in the previews sections. 
\subsection{Signing up}
Every PA user signs up for the first time with his or her email address and password for login in. The application sends the email address and device-token present on the device to the back-office. With this device-token the server can send push messages via the APNS server for iOS devices or via the google C2DM server for Android to the devices. These servers send push messages to the devices with a JSON payload. This brings a solutions for conserving battery life. The PA does not have to poll for any new incoming requests. See \ref{fig:signup} for the route. The payload is specified in the following subsections.

\begin{figure}[h!]
\centerline{
\xymatrix{
*+<10ex>[F]{Database} & *+<10ex>[F]{Back-office}\ar[l]^{\txt<10pc>{store user}}\ar[rr]^{\txt{Device Token + \\ JSON Payload}}& &*+<10ex>[F]{C2DM / APNS} \ar[dl]^{\txt<5pc>{Ability \\ to Push Messages}} \\
&  & *+<6ex>[F]{Device}\ar[ul]^{\txt<10pc>{Email + \\  JSON Payload}} &
}
}
\caption{Server Signup and push messages}
\label{fig:signup}
\end{figure}

\subsection{Data format}
The data format to represent the data is an ICS file. It is no more than an database file where convention is applied upon. The ICS format is commonly used as the raw data for a calender. With this data format it is possible to send an event and tasks to others. These files can be shared by each others in order to see each others calender. By showing these calenders in one scheme the user can make decision on planning an appointment at a certain time. 

An ICS file consists of a single Calender object but can also consist of multiple Calenders. Such a file starts with BEGIN:VCALENDAR en ends with END:VCALENDAR. Everything in between is called the \textit{icalbody}. This body is build up out of properties and one or more calender components. These properties and components are used by the personal assistant to represent the agenda and calculate the best date between other calenders. 
An event is made by stating an BEGIN:VEVENT and end with END:VEVENT. An event has multiple properties such as:
\begin{itemize}
\item UID - email address of the owner of the calendar
\item DTSTAMP - date created
\item ORGANIZER - the email address that is concidered the host of the event 
\item ATTENDEE - mail address of the attendee (can be more)
\item DTSTART - start of event
\item DTEND - end of event
\item SEQUENCE - count of the event sequence. 
\item DESCRIPTION - description, in words
\end{itemize}
These are certainly not the only properties that a VEVENT can have but shows the possibility of the information inside an event. The ICS file properties/protocol is described in rfc5546 \cite{rfc5546}, the updated version of the original rfc2446 \cite{rfc2446}. These VEVENTS are encapsulated in a JSON object, see figure \ref{fig:vevent}. The ICS file is eventually constructed by the PA of the creator of the event. This file is distributed by the back-office to all the invitees.


\subsection{Finding the best appointment}
\subsubsection{Request}
The creator collects the open gaps in the schedule of all the participators, with scores attached. These scores are collected during the learning process or calculated from other parameters (not occupied, user never wants to meet at requested time etc.. ). Finding the best appointment will be done by the creator's PA. These messages are send in a JSON object to the back-office. The creator connects to the back-office with his email address and device token. In the JSON object the fields of the request are stored. With this email address the device-token is lookup in the database. Next, the JSON request are send to the APNS server for iOS or the C2DM server for Android, which then sends push messages to all participators. See figure \ref{fig:request} for the route that is used in the system.

\begin{figure}[h!]
\centerline{
\xymatrix{
 *+<10ex>[F]{Back-office}\ar[rr]^{\txt{Device Token + \\ JSON Payload}}& &*+<10ex>[F]{C2DM / APNS} \ar[ddll]\ar[ddl]\ar[dd]^{\txt{JSON Payload}}  \\
 *+<6ex>[F]{Creator}\ar[u]^{\txt{request for gaps}} & & \\
*+<6ex>[F]{Participator1} & *+<6ex>[F]{Participator2} & *+<6ex>[F]{Participator3}
}
}
\caption{The route of the request for retrieving the gaps of the participators}
\label{fig:request}
\end{figure}
\pagebreak
\begin{figure}[h!]
\begin{lstlisting}
{
	"request":
	{
		"id": base36,
		"name" : "Foo Meeting",	
		"creator": "creator@foo.com",
		"kind": "Meeting"
		"interval": {
                         "startDate": ddmmyyyy
                         "startTime": hh:mm
                         "duration": hh:mm
                         "endTime": hh:mm
                         "endDate": ddmmyyyy
                       }
		"location": "FooCity",
		"participators": ["participator1@foo.com",
		     "participator2@foo.com", ".."],
	}
}
\end{lstlisting}
\caption{The request body for gaps and scores.}
\label{fig:requestGaps}
\end{figure}

This is the request package that is send by the creator to the server. The server reacts with sending push messages to the PA's of the participators that are linked with their e-mail address and Device-Token, see figure \ref{fig:respond}. The PA's of the participators respond with sending back the scores and gaps in the interval specified by the creator. The data fields of the interval consists of starting date, start time, end time, duration and end date. Participators respond with sending the gaps in their schedule calculated in the requested interval. By requesting bigger intervals, more options can given. All the scores and gaps are accumulated, this can be seen in figure \ref{gapsEval}. The gap with the highest score is presented as option number one.

\begin{figure}[h!]
\centerline{
\xymatrix{
*+<10ex>[F]{Database} & *+<10ex>[F]{Back-office}\ar[l]^{\txt{Look up \\ Device Token}}\ar[rr]^{\txt{JSON response}} & &*+<10ex>[F]{C2DM / APNS} \ar[lld]  \\
&*+<6ex>[F]{Creator} & & \\
& *+<6ex>[F]{Participator1}\ar@/^4pc/[uu]^{\txt{JSON response \\ with e-mail}} & *+<6ex>[F]{Participator2}\ar[uul] & *+<6ex>[F]{Participator3}\ar[uull]
}
}
\caption{Response for gaps}
\label{fig:respond}
\end{figure}

The response is an array with intervals and scores. These scores can be manually given or calculated for the user. The default amount is 100 points, over time the PA learns from its user to change these scores. For example with the knowledge of weather and public transport the scores van be adjusted. When a user prefers not to use the bike when it rains, the scores can change. The score totally depends on the probability of attending the appointment. Travelling with public transport \emph{can} take longer than with taking the bike. If there is a gap that closely follows another appointment the score decreases, it decreases even more when both events are at a different location. Given the fact that it rains, the score goes down further. How much the score decreases or increases depends on how much time it costs for travelling from the last event to the next event. 

\begin{figure}[here]
\center
	\begin{tabular}{l|c}
		\includegraphics[scale=1.4]{pa.png} & \includegraphics[scale=1.4]{pa2.png}
	\end{tabular}
\caption{Steps of evaluating the gaps given by participators, in this case 2 participators}
\label{gapsEval}
\end{figure}
\begin{figure}[h!]
\begin{lstlisting}
{
	"response": 
	{
		"id":base36,
		"creator": "creator@foo.com",
		"participator": "participator1",
		"gaps":
		[
			["ddmmyy", hh:mm, 100],
			["ddmmyy", hh:mm, 20],
			["ddmmyy", hh:mm, 50],
		]	
	}
}
\end{lstlisting}
\caption{The response body}
\label{fig:vevent}
\end{figure}
\pagebreak

\subsection{Fall back}
As explained in section \ref{sec:designConsiderations} the PA needs to have a fall back when not every participators uses the PA system. This is handled at server side. The creator of the event does not notice if somebody \emph{is} using the PA or \emph{not}. When the server can not find a record of the email address of a participator, it sends an email in stead of a push messages. The email will contain link to a webform that can be filled in much like \url{www.datumprikker.nl} \cite{datumprikker}. The interval of the request is presented in the webform, and those users have to manually provide the gaps in their schedule. They also have to say a how much the gap they provided is preferred, giving a range between 0 and 100. 
The server handles the data that has been provided by them, and wraps this in the same JSON object as if it was send by a PA application.


\subsection{Scalability}
The server is an asynchronous/event-driven server. Which means that all socket streams are polled asynchronously, fast switching between one socket stream and another. By doing this the scalability is preserved. The other alternative would be to change to start a thread for every client. This is not scalable at all. A thread uses a whole stack frame in memory, this means that a lot memory is used for a user. The agenda has to be available for everyone and the goal for this application is to serve a lot of users.
By choosing asynchronous the server will not create a Thread for every user but loops trough all the sockets and can handle thousands connection at a time. Threads cause a lot of overhead in locking memory for reading or writing. This is not the case with asynchronous.

\subsection{Flow}
To round this section up, this flow graph shows the route that is taken from start to finish. It's not a complicated flow graph but it shows the steps in some what different perspective.
\begin{figure}[h!]
\centering
\includegraphics[scale=0.6]{flowchart_pa.png}
\caption{flow in process}
\end{figure}
